Fluid + GooseFS 助力云原生数据编排与加速快速落地
谢远东,腾讯高级工程师,云原生机器学习社区 Kubeflow Member、 云原生数据编排与加速框架 Fluid(CNCF Sandbox) 核心开发者、Istio Member ,负责腾讯云 TKE 在 AI 场景的研发和支持工作。
彭芳,腾讯云容器产品经理,负责腾讯云 TKE 在存储、安全和云原生etcd服务的产品策划工作。
前言
现状和挑战
什么是存算分离架构?
云原生存算分离架构面临的挑战?
云平台存算分离架构导致数据访问延时高。随着高速网络设备和负载的大规模使用,所有的数据都依赖网络 IO 到计算节点计算和汇总,尤其是数据密集型应用,大概率网络会成为瓶颈(没有银弹)。IO 的瓶颈最终会导致计算和存储的资源无法充分的利用,将会背离利用云来实现降本增效的初衷。
混合云场景下跨存储系统的联合分析困难。大多数公司的业务线可能会分为不同的小组,不同的小组针对不同的 Workload 使用的计算框架也各有不同,而框架支持的存储也各有特点。例如 HDFS 针对大数据领域、Lustre 针对超算领域等等。当需要联合数据进行综合性分析时,数据副本数增加、数据转换的成本增加,都必然导致资源(即人力)的成本增高、业务迭代的效率降低等风险。
云中数据安全治理与多维度管理日趋复杂。数据是很多公司的生命线,数据泄露、误操作、生命周期管理不当都会造成巨大损失。如何在云原生环境中保障数据隔离,保护好用户的数据生命周期,都存在较大挑战。
Fluid 能做什么?
GooseFS & Fluid 探究
云原生数据湖加速器 GooseFS
分布式数据编排和加速框架 Fluid
通过数据亲和性调度和分布式缓存引擎加速,实现数据和计算之间的融合,从而加速计算对数据的访问;
将数据独立于存储进行管理,并且通过 Kubernetes 的命名空间进行资源隔离,实现数据的安全隔离;
将来自不同存储的数据联合起来进行运算,从而有机会打破不同存储的差异性带来的数据孤岛效应。
理清 TKE、Fluid 和 GooseFS 之间的关系
计算调度层:TKE 以 Kubernetes 环境为底座提供了容器应用的部署平台,Fluid GooseFS 控制器将控制 GooseFS 实例中的 Master Pod、Worker Pod 以及 Fuse Pod 创建在最合适的 TKE Worker 节点。
存储层:控制器会根据用户指定的数据来源将底层存储例如 COS、HDFS 的数据缓存到 Worker Pod 中。
任务层:任务 pod 指定持久化存储卷,控制器 webhook 会注入亲和性信息,以实现将使用缓存任务优先调度到有缓存节点以及将不使用缓存任务先调度到没有缓存节点的目标。
Fluid v0.6.0 特性体验
“缓存引擎高可用运行时”
“新增数据缓存引擎实现 GooseFSRuntime”
特性 Demo
前提条件
$ kubectl get pod -n fluid-system
goosefsruntime-controller-5b64fdbbb-84pc6 1/1 Running 0 8h
csi-nodeplugin-fluid-fwgjh 2/2 Running 0 8h
csi-nodeplugin-fluid-ll8bq 2/2 Running 0 8h
csi-nodeplugin-fluid-dhz7d 2/2 Running 0 8h
dataset-controller-5b7848dbbb-n44dj 1/1 Running 0 8h
dataset-controller
的 pod、一个名为 goosefsruntime-controller
的 pod 和多个名为csi-nodeplugin
的 pod 正在运行。其中,csi-nodeplugin
这些 pod 的数量取决于你的 Kubernetes 集群中结点的数量。新建工作环境
$ mkdir <any-path>/demo
$ cd <any-path>/demo
查看全部节点
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
192.168.1.145 Ready <none> 7d14h v1.18.4-tke.13
192.168.1.146 Ready <none> 7d14h v1.18.4-tke.13
192.168.1.147 Ready <none> 7d14h v1.18.4-tke.13
创建 Dataset 资源
cat >> dataset.yaml <<EOF
apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
name: hbase
spec:
mounts:
- mountPoint: https://mirrors.tuna.tsinghua.edu.cn/apache/hbase/stable/
name: hbase
EOF
$ kubectl create -f dataset.yaml
dataset.data.fluid.io/hbase created
mountPoint 这里为了方便用户进行实验使用的是 Web UFS, 使用 COS 作为 UFS 可见 加速 COS[6]。
创建并查看 GooseFSRuntime 资源
cat >> runtime.yaml <<EOF
apiVersion: data.fluid.io/v1alpha1
kind: GooseFSRuntime
metadata:
name: hbase
spec:
replicas: 3
tieredstore:
levels:
- mediumtype: MEM
path: /dev/shm
quota: 2G
high: "0.8"
low: "0.7"
master:
replicas: 3
EOF
$ kubectl create -f runtime.yaml
goosefsruntime.data.fluid.io/hbase created
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
hbase-fuse-4v9mq 1/1 Running 0 84s
hbase-fuse-5kjbj 1/1 Running 0 84s
hbase-fuse-tp2q2 1/1 Running 0 84s
hbase-master-0 1/1 Running 0 104s
hbase-master-1 1/1 Running 0 102s
hbase-master-2 1/1 Running 0 100s
hbase-worker-cx8x7 1/1 Running 0 84s
hbase-worker-fjsr6 1/1 Running 0 84s
hbase-worker-fvpgc 1/1 Running 0 84s
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
hbase Bound default-hbase 100Gi ROX fluid 12h
$ kubectl get goosefsruntime
NAME MASTER PHASE WORKER PHASE FUSE PHASE AGE
hbase Ready Ready Ready 15m
$ kubectl exec -ti hbase-master-0 bash
# 可以看到其中一个节点是 LEADER 其余两个是 FOLLOWER
$ goosefs fs masterInfo
current leader master: hbase-master-0:26000
All masters: [hbase-master-0:26000, hbase-master-1:26000, hbase-master-2:26000]
到这里,我们已经创建了可以供计算任务访问的分布式缓存引擎 GooseFS,计算任务的 pod 只需要指定
persistentVolumeClaim.name
为 hbase 即可获取缓存加速的能力。同时只需要通过指定
spec.master.replicas=n
,这里 n 为大于等于 3 的奇数,就可以直接开启 Master HA 模式。只需要指定
spec.replicas=n
,控制器将为 GooseFS 缓存系统创建 3 个 worker pod 以及 3 fuse pod
数据预热和加速
// 不使用缓存情况下任务时间
$ cat >> nginx.yaml <<EOF
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx
volumeMounts:
- mountPath: /data
name: hbase-vol
volumes:
- name: hbase-vol
persistentVolumeClaim:
claimName: hbase # 挂载 pvc claimName 和 dataset 一致
EOF
$ kubectl create -f nginx.yaml
$ kubectl exec -it nginx /bin/bash
$ root@nginx:/# time cp -r /data/hbase /
real 1m9.031s
user 0m0.000s
sys 0m2.101s
$ kubectl delete -f nginx.yaml
// 使用缓存加速
// 创建 Dataload 资源
$ cat >> dataload.yaml <<EOF
apiVersion: data.fluid.io/v1alpha1
kind: DataLoad
metadata:
name: hbase-dataload
spec:
dataset:
name: hbase
namespace: default
target:
- path: /
replicas: 1
EOF
$ kubectl create -f dataload.yaml
// 查看缓存预热进度
$ kubectl get dataset hbase --watch
NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE
hbase 545.32MiB 545.32MiB 5.59GiB 100.0% Bound 16m
$ kubectl create -f nginx.yaml
$ kubectl exec -it nginx /bin/bash
$ root@nginx:/# time cp -r /data/hbase /
real 0m0.278s
user 0m0.000s
sys 0m0.273s
这里主要展示 v0.6.0 的两大功能:缓存引擎高可用运行时以及新增数据缓存引擎实现 GooseFSRuntime ,不涉及 Fluid 其他功能,其他功能可见 使用文档[7]。
Fluid Roadmap
弹性拓展方面,目前已经支持基于自定义指标对缓存 Worker 进行 HPA(Horizontal Pod Autoscaler) 以及针对业务波峰波谷的 CronHPA 。但是由于缓存引擎数据再平衡(re-balance)功能的缺失,目前无法利用扩缩容达到降本增效的目的,这个也是社区后期重点关注的特性。
Fluid Agent 方面,通过 agent push 模式,上报一些关键的运维指标例如是否有残留需要清理、节点是否有缓存等;同时不同节点上的系统信息例如 cpu/memory 使用量、磁盘使用量、page cache 使用信息等,通过这些信息可以指导 fluid 调度器对数据集进行最优调度。
调度策略方面,目前主要涉及三个方面的调度:
数据集调度:目前已经适配 kubernetes 调度,例如 Toleration、Node Selector、Preferred 调度;后期我们希望以 Scheduling Framework 的方式通过 Filter、Scoring、Binding 等操作实现数据集最优调度。
任务调度:目前已经可以通过 webhook 自动对指定 namespace 下的负载加入亲和性和反亲和性标签进行任务调度;
任务调度和数据预热协同调度:通过调度信息对 Job Queue 中 Job 使用的数据进行预加载,达到流水线优化的目的。
总结与展望
参考资料
v0.6.0: 【https://github.com/fluid-cloudnative/fluid/releases/tag/v0.6.0】
[2]《2020年中国云原生报告》:【 https://www.cncf.io/blog/2021/04/28/cncf-cloud-native-survey-china-2020/】
[3](Data Lake Accelerator Goose FileSystem,GooseFS): 【https://cloud.tencent.com/document/product/436/56412】
[4]CNCF Sandbox: 【https://www.cncf.io/sandbox-projects/】
[5]安装文档: 【https://cloud.tencent.com/document/product/436/59493】
[6]加速 COS: 【https://cloud.tencent.com/document/product/436/59499】
[7]使用文档: 【https://cloud.tencent.com/document/product/436/59495】
互动赢好礼
精读文章,回答问题赢好礼
Q1: Fluid 主要通过哪两种方式达到应用加速的目的?
Q2: TKE Node 节点在云原生数据编排加速体系中的作用是什么?精读本文,回答以上2个问题。至8月17日上午12点前,将从留言处选出答案最优质及点赞数量最高的前3名,送腾讯周边可爱短鹅一只。
往期精选推荐